持久化：

redis基于内存是数据库，内容存到内存中，也可以存到硬盘中，这个过程就叫持久化。有两种方案，RDB和AOP两种。

RDB持久化就是把当前进程数据生成快照保存到硬盘的过程RDB文件是⼀个压缩的二进制文件，通过它可以还原某个时刻数据库的状态。由于R DB文件是保存在硬盘上的，所以即使Redis崩溃或者退出，只要RDB文件存在，就可以用它来恢复还原数据库的状态。

触发RDB持久化过程分为手动触发和自动触发。

分别对应save和bgsave命令:

以下场景会自动触发RDB持久化：

Fork的作用是复制一个与当前进程一样的子进程，新进程所有的数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。它用写时复制技术，即现将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换持久化好的文件。

 一般情况下父进程和子进程会公用一段物理内存，只有进程空间的各段内容要发生变化时，才将父进程的内容复制一份给子进程。

bgsave流程图：

1 . 只有⼀个紧凑的⼆进制文件dump.rdb，非常适合备份、全量复制的场景。

2 . 容灾性好，可以把RDB文件拷贝到远程机器或者文件系统中，用于容灾恢复。

3 . 恢复速度快，RDB恢复数据的速度远远快于AOF的方式

1、实时性低，RDB是间隔⼀段时间进行持久化，没法做到实时持久化/秒级持久化。如果在这⼀间 隔事件发生故障，数据会丢失（会丢失最后一次快照的所有修改）。

2、存在兼容问题，Redis演进过程存在多个格式的RDB版本，存在老版本Redis无法兼容新版本R DB的问题。

3、Fork的时候，内存中的数据被克隆了一份，大致两倍的膨胀量需要考虑。数据量庞大时消耗性能。

AOF持久化：以独立日志的方式记录每次写命令（读操作不记录），redis重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志，性能较差但是数据完整性较好。

appendfsync everysec

每秒同步，每秒记入一次日志，如果宕机，本秒的数据会丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

流程图：

流程如下：

1）所有的写入命令会追加到aof _ buf（缓冲区）中。

2）AOF缓冲区根据对应的策略向硬盘做同步操作。

3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

1 . 实时性好，aof 持久化可以配置 appendfsync 属性，有 always ，每进行⼀次命令操作就记录 到 aof 文件中⼀次。

2 . 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis- check - aof 工具解决数据⼀致性问题。

1、AOF文件比RDB文件大，且恢复速度慢。

2 . 数据集大的时候，比RDB启动效率低。